[Previous] [Next] [Index]
[Thread]
Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD
I think this demonstrates precisely why we need different authentication
systems. Public key is slow. Kerberos is fast but requires a trusted
intermediary. For many security scenarios this is OK. Especially if you
have already set up kerberos.
I would argue that in many on-line client/server scenarios (such as
the WWW) even the public key approach will require a trusted
intermediary. I.e., I don't think on-line services will be able to
depend on CRLs for detecting invalid (old, stolen, etc.) public key
certificates, both for timeliness and performance considerations. I
think they will need to rely on an on-line trusted intermediary to
validate the certificates, especially when financial transactions are
involved. For more "loosely-coupled" applications, like privacy
enhanced mail, using CRLs may be fine.
The idea is to modularise the library so that a person with a proverbial
good idea can easily fing a hook to fasten it to - in any area. So a person
with a new transformer - encryption, compression, image handling, formatting,
etc can just call a routine to slot something in.
Wrt security/encryption, having hooks in a common library sounds
great. However, it seems that there are several other issues to be
addressed for interoperability, like security mechanism negotiation
between client and server, standard encryption encapsulation formats,
etc. I.e., various implementations could hook in there own RSA
modules, but that doesn't insure any two of them can interoperate.
I know that S-HTTP is trying to address some of this, as is the IETF
CAT. However, there's so much to choose from (RSA/DSA,
PKCS/PEM/PGP/SPKM, etc.).
Of course we are not there now but that is where we want to be :-)
Great; I hope many of the other issues can be standardized as well.
- Doug
References: